如何管理客戶期望

開始之前，且聽Odoo 始創人 Fabien 娓娓道來：

「幾年前，一位潛在客戶的執行長要求我在簽署合約之前會面。她告訴我「這個計畫對我公司來說是生死攸關的，請告訴我一切都會順利」。我這樣回答：「不。這樣的項目確實很難。我們會有很多問題。但最終，你的公司會變得更好。當你的團隊抱怨時，我需要你作為首席執行官支持該項目，以克服這些困難。」
直到兩年後，執行長打電話給我時，我才收到這位客戶的回覆。專案嚴重延遲，關鍵用戶對產品失去信任。執行長告訴我的第一件事就是：「這個計畫是一場噩夢，我們晚了 12 個月，而且我看不到結局。但我按照你的要求做了：我一直支持這個項目，我從來沒有在團隊面前批評你的產品，並且總是激勵那些想要放棄這個項目的關鍵用戶。但是，現在，我們已經到了極限，我需要你為我做一件事…」
所以，簽訂合約前與CEO的這兩分鐘實際上挽救了這個專案。如果執行長站在關鍵用戶這邊，該專案就會在幾個月前就中止。由於她認真地支持該項目，該項目得以保存，並在兩個月後部署到生產中。
　
-Fabien - Odoo 創始人，談及首位購買銷售點（POS）應用程式的客戶。

這個故事完美地說明了管理客戶期望的力量。
如果 Fabien 說「別擔心，這個項目很容易」，首席執行官就會對這個項目失去信任，並且很可能在很久以前緊張局勢嚴重升級時就聽從了關鍵用戶的建議。

如何寫出一份好的規範

好的規範應該簡短、直覺且結構如下：
• 業務需求： 用幾句話解釋開發需求背後的原因。是什麼讓發展成為必要的？
• 功能分析： 模型或附註解的螢幕截圖。
• 技術提示： 開發人員必須注意的事項。

👉 好規範例子 https://link.excalidraw.com/l/65VNwvy7c4X/11FJkoHvkDu

避免導入資料歷史記錄

除了主資料之外，客戶經常要求匯入完整的資料歷史記錄，例如 7 年前的報價和銷售情況。這需要花費大量時間，並且會佔用很大一部分預算，因為它增加了專案成功的風險。
只有在真正合理的情況下才必須這樣做，最好是在上線之後。

問以下問題檢查是否確實有必要：
• 是否可以將該資訊保留在舊軟體或匯出檔案中？
• 您的客戶多久查閱一次該資訊？出於什麼目的？
• 2、3 或4 年後可能產生什麼策略影響？
就像任何其他請求一樣，只要客戶無法說服您需要，則需要拒絕匯入請求，或延遲到上線之後。

避免為客戶撰寫文檔

實施 Odoo 時，您可能會被迫建立特定文件以簡化最終使用者的入門流程。即使這看起來是個好主意，你也會意識到你所能帶來的價值不值得投入時間。身為專案負責人，您需要專注於只有您才能完成的任務。
換句話說，專案負責人不得浪費時間重複整個專案中已經給出的解釋。客戶需要負責根據自己的業務案例和術語建立自己的文件。
此外，單一聯絡人SPoC 是客戶端所有 Odoo 實施利害關係人中擁有最廣泛業務知識的人。
此外，讓客戶編寫自己的文件可以確保 單一聯絡人SPoC 正確理解和處理配置的 Odoo 工作流程。這簡化了變更管理流程，因為最終使用者可以直接存取自己公司的可靠知識來源。有些客戶甚至擁有自己的 Odoo 專家團隊，為公司處理 Odoo 的所有事務。
當然，現有文件已經涵蓋了大多數標準流程，Odoo 在線上共享所有知識。小型專案通常不需要特定的文件。